I was going the same way with JointStaturation Limiter when extending for double limits. What I see here that we have very similar calculation in the RangeLimmiter and the JointSaturationLimiters. So here the question. Why not to add additional on_enfoce method to the interface that implements also this kind of limiting and then extend JointSatutrationLimiter (where we reuse most of the calculations).

This way we make sure that when we implement actually another type of limiter, we will make sure that all methods are implemtend too.

@destogl sorry that I didn't leave any proper description in the PR. I went through the math inside your JointStaturationLimiter it is very well done for trajectories but the same cannot be applied to the CommandInterfaces and StateInterfaces

• For instance, When you are in position control may be the velocity control is not active, then the desired velocity inside this handle will be zero and then basically you will make the position not move at all and also there are different cases that doesn't correspond to individual usecases. Likewise, there are other couple of things that mightn't work, so we will need one more thing for sure.
• You are checking the dynamics constraints between the points, which is completely makes sense for those trajectories, and for the joint commands, we will have many issues. We can discuss about this.
• We have to keep the joints data separate in the ResourceManager as if the joints belong to different HW components, the activation and deactivation of those particular joints shouldn't hinder the JointLimits in any way, so in this way it is more detached and modular in my opinion

What do you think about it?

@destogl thanks for taking time to do the review. I have left my comments, we can discuss it over here or over a call as you prefer.

After the call, We have decided to the merge the joint_range_limiter into the joint_saturation_limiter. So the idea is to reuse the header of the JointSaturationLimiter and create different .cpp files to have different plugin types, and this way we will be able to change the type and create plugins.

We have also discussed about adding the hard limits into the SoftLimits struct or create a whole new structure with hard_limits and optional soft limits, some thing like below

// We could think of a proper naming
struct JointURDFLimits
{
   std::optional<JointLimits> hard_limits_;
   std::optional<SoftJointLimits> soft_limits_;
}